
United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 

Address: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria. Virginia 223I3-14S0 
www.uspto.gov 



APPLICATION NO. 


FILING DATE 


FIRST NAMED INVENTOR 


ATTORNEY DOCKET NO. 


CONFIRMATION NO. 


10/690,762 


10/22/2003 


Nitzan Peleg 


200308558-1 


5363 



22879 7590 12/11/2007 

HEWLETT PACKARD COMPANY 
P O BOX 272400, 3404 E. HARMONY ROAD 
INTELLECTUAL PROPERTY ADMINISTRATION 
FORT COLLINS, CO 80527-2400 



EXAMINER 



TIMBLIN, ROBERT M 



ART UNIT 



2167 



PAPER NUMBER 



NOTIFICATION DATE 



DELIVERY MODE 



12/1 1/2007 



ELECTRONIC 



Please find below and/or attached an Office communication concerning this application or proceeding. 

The time period for reply, if any, is set in the attached communication. 

Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the 
following e-mail address(es): 

JERRY,SHORMA@HP.COM 

mkraft@hp.com 

ipa.mail@hp.com 



PTOL-90A (Rev. 04/07) 




United States Patent and Trademark Office 



Commissioner for Patents 
United States Patent and Trademark Office 

P.O. Box 1450 
Alexandria, VA 22313-1450 

www.uspto.gov 



MAILED 

DEC 0 7 mi 
Technology Center 2100 

BEFORE THE BOARD OF PATENT APPEALS 
AND INTERFERENCES 



Application Number: 10/690,762 
Filing Date: October 22, 2003 
Appellant(s): PELEG ETAL. 



W. Allen Powell 
For Appellant 

EXAMINER'S ANSWER 



This is in response to the appeal brief filed 9/13/2007 appealing from the Office action 
mailed 4/9/2007. 



Application/Control Number: Page 2 

10/690,762 

Art Unit: 2167 

(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 
WITHDRAWN REJECTIONS 

The following grounds of rejection are not presented for review on appeal 
because they have been withdrawn by the examiner. The Examiner has withdrawn the 
rejection of claims 1, 5, 9, 16, and 27 under 35 U.S.C. 112 second paragraph. 

The appellant's statement of the second and third grounds of rejection to be 
reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 
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(8) Evidence Relied Upon 

6,125,360 Witkowskietal. 9-2000 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claim Rejections - 35 USC § 101 

35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

Claims 1-4 are rejected under 35 U.S.C. 101 because no implementation of 
computer hardware is found in these claims. The lack of computer hardware renders 
claims 1-4 as being software per se and therefore is nonfunctional descriptive material. 

Claim Rejections - 35 USC § 102 

The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent, unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

Claims 1-30 are rejected under 35 U.S.C 102(b) as being anticipated by 
Witkowski et al CWitkowski' hereafter) (U.S. Patent 6,125,360). 
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With respect to claim 1 , Witkowski teaches a system that allows a table and a 
materialized view to be available while the materialized view is being refreshed, the 
system comprising: 

a materialized view that is derived at least in part from a table (abstract and col. 4 

line 37-41); 

a refresh log that contains a plurality of entries (col. 9 line 40-50, col. 16 line 17- 
24 and figure 4c), each of the plurality of entries corresponding to a change in the table 
(col. 9 line 12-23, col. 16 line 17-33 and figure 4c), each of the plurality of entries 
comprising an epoch identifier (SCN) adapted to synchronize the refresh log between 
refreshing operations (col. 9 line 25-33); and 

a refresh manager (figure 3) that performs a refresh operation on the 
materialized view in multiple steps by (a) successively reading a first subset of the 
plurality of entries indicated by a specific epoch identifier from the refresh log (col. 9 line 
55-60), (b) identifying a second subset of the plurality of entries from within the first 
subset of the plurality of entries, the second subset of the plurality of entries falling 
within a primary key value boundary (database queries of columns 9 and 10) and (c) 
applying the second subset of the plurality of entries to the materialized view (col. 9 line 
25-33). 

With respect to claim 2, Witkowski teaches the system set forth in claim 1, 
wherein the corresponding epoch identifiers represent epoch numbers that have been 
created since a previous refresh operation on the materialized view (col. 9 line 18-23). 
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With respect to claim 3, Witkowski teaches the system set forth in claim 1, 
wherein the second subset of the plurality of entries is applied to the materialized view 
in a primary key order (col. 9 line 25-37 and figure 7). 

With respect to claim 4, Witkowski teaches the system set forth in claim 1, 
wherein the refresh manager is adapted to distinguish between entries of the second 
subset of the plurality of entries that have already been applied to the materialized view 
in previous transactions and entries of the second subset of the plurality of entries that 
have not been applied to the materialized view in the event of a failure of the refresh 
operation (col. 9 line 55-col. 10 line 7 and col. 9 line 34-39). 

With respect to claim 5, Witkowski teaches A method of refreshing a materialized 
view that is in part derived from a table, the method being adapted to improve the 
availability of the table and the materialized view while the materialized view is being 
refreshed, the method comprising: 

deriving a materialized view from at least one table (abstract and col. 4 line 37- 

41); 

assigning an epoch identifier (SCN) to changes made to the at least one table 
(col. 9 line 12-23, col. 16 line 17-33 and figure 4c); 

storing an entry corresponding to each change to the at least one table in a 
refresh log that includes a plurality of entries (col. 9 line 40-50, col. 16 line 17-24 and 
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figure 4c), each of the plurality of entries comprising an epoch identifier (SCN) that is 
adapted to synchronize the refresh log between refreshing operations (col. 9 line 25- 
33); and 

performing a refresh operation in multiple operations (col. 9, Incremental Refresh 
Operation), each of the multiple operations comprising (a) successively reading a first 
subset of the plurality of entries indicated by a specific epoch identifier from the refresh 
log (col. 9 line 55-60), (b) identifying a second subset of the plurality of entries from 
within the first subset of the plurality of entries, the second subset of the plurality of 
entries falling within a primary key value boundary (database queries of columns 9 and 
10) and (c) applying the second subset of the plurality of entries to the materialized view 
(col. 9 line 25-33). 

With respect to claim 6, Witkowski teaches the method set forth in claim 5, 
comprising applying the second subset of the plurality of entries to the materialized view 
in a primary key order (col. 9 line 25-37 and figure 7). 

With respect to claim 7, Witkowski teaches the method set forth in claim 5, 
comprising defining the epoch identifier to correspond to changes that have been made 
to the table since a previous refresh operation on the materialized view (col. 9 line 18- 
23). 
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With respect to claim 8, Witkowski teaches the method set forth in claim 5, 
comprising distinguishing between entries of the second subset of the plurality of entries 
that have already been applied to the materialized view in previous transactions and 
entries of the second subset of the plurality of entries that have not been applied to the 
materialized. view in the event of a failure of the refresh operation (col. 9 line 55-col. 10 
line 7 and col. 9 line 34-39). 

With respect to claim 9, Witkowski teaches A system that provides availability of 
a table and a materialized view while the materialized view is being refreshed, the table 
being derived at least in part from the materialized view, the system comprising: 

a refresh log that contains a plurality of entries (col. 9 line 40-50, col. 16 line 17- 
24 and figure 4c), wherein the plurality of entries comprise data that is being refreshed 
(col. 9 line 24-67), each of the plurality of entries comprising an epoch identifier adapted 
to synchronize the refresh log between refreshing operations (col. 9 line 25-33); and 

a refresh manager (figure 3) that computes a table delta (col. 9 line 13-26) based 
on the refresh log (col. 15 line 24-40 and col. 16 line 17 Iine1-10) and applies the table 
delta to the materialized view (col. 1 5 line 40-47 and figure 5). 

With respect to claim 10, Witkowski teaches the system set forth in claim 9, 
wherein each of the plurality of entries comprises an epoch identifier (col. 9 line 18-23 
SCN). 
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With respect to claim 11, Witkowski teaches the system set forth in claim 10, 
wherein the epoch identifier corresponds to changes that have been made to the table 
since a previous refresh operation on the materialized view (col. 9 line 18-23). 

With respect to claim 12, Witkowski teaches the system set forth in claim 9, 
wherein the table delta is applied to the materialized view in a primary key order (col. 9 
line 25-37 and figure 7). 

With respect to claim 13, Witkowski teaches the system set forth in claim 9, 
wherein the table delta is used to refresh the materialized view in multiple transactions 
(col. 9 line 25-37 and figure 7). 

With respect to claim 14, Witkowski teaches the system set forth in claim 9, 
wherein a primary key value for each entry from the refresh log is recorded after that 
entry is applied to the materialized view (col. 16 line 18-24 and figure 4c). 

With respect to claim 15, Witkowski teaches the system for refreshing the 
materialized view set forth in claim 9, wherein the refresh manager is adapted to 
distinguish between a first subset of the plurality of entries that have already been 
applied to the materialized view in previous transactions and a second subset of the 
plurality of entries that have not been applied to the materialized view in the event of a 
failure of the refresh operation (col. 9 line 55-coL 10 line 7 and col. 9 line 34-39). 
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With respect to claim 16, Witkowski teaches a method of refreshing a 
materialized view that is derived at least in part from a table, the method being adapted 
to provide availability of the table and the materialized view while the materialized view 
is being refreshed, the method comprising the acts of: 

storing a plurality of entries corresponding to changes in the table in a refresh log 
wherein the plurality of entries comprise data that is being refreshed (col. 9 line 40-50, 
col. 16 line 17-24 and figure 4c), each of the plurality of entries comprising an epoch 
identifier (SCN) adapted to synchronize the refresh log between refreshing operations 
(col. 9 line 25-33); 

computing a table delta based on the refresh log (col. 9 line 13-26 and col. 15 
line 25-32); 

refreshing the materialized view based on the table delta (abstract and col. 9 
Incremental Refresh Operation section). 

With respect to claim 17, Witkowski teaches the method set forth in claim 16, 
wherein the table delta is applied to the materialized view in a primary key order (col. 9 
line 25-37 and figure 7). 

With respect to claim 18, Witkowski teaches 18 the method set forth in claim 16, 
comprising updating the materialized view in multiple transactions (col. 9 line 25-37 and 
figure 7). 
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With respect to claim 19, Witkowski teaches the method set forth in claim 16, 
comprising storing an epoch identifier as a portion of each of the plurality of entries (col. 
9 line 18-23 SCN). 

With respect to claim 20, Witkowski teaches the method set forth in claim 19, 
comprising defining the epoch identifier to correspond to changes that have been made 
to the table since a previous refresh operation on the materialized view (col. 9 line 18- 
23). 

With respect to claim 21, Witkowski teaches the method set forth in claim 16, 
comprising recording the primary key value for each entry from the update log after that 
entry is applied to the materialized view (col. 16 line 18-24 and figure 4c). 

With respect to claim 22, Witkowski teaches the method set forth in claim 16, 
comprising distinguishing between a first subset of the plurality of entries that have 
already been applied to the materialized view in previous transactions and a second 
subset of the plurality of entries that have not been applied to the materialized view in 
the event of a failure of the act of refreshing the materialized view (col. 9 line 55-col. 10 
line 7 and col. 9 line 34-39). 
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With respect to claim 23, Witkowski teaches a system that provides availability of 
a table and a materialized view while the materialized view is being refreshed, the table 
being derived at least in part from the materialized view, the system comprising: 

a refresh log that contains a plurality of entries (col. 9 line 40-50, col. 16 line 17- 
24 and figure 4c), wherein the plurality of entries comprise data that is being refreshed 
(col. 9 line 24-67), each of the plurality of entries comprising an epoch identifier adapted 
to synchronize the refresh log between refreshing operations (col. 9 line 25-33); and 

means for computing a . table delta based on the refresh log (col. 9 line 13-26 and 
col. 15 line 25-32); and 

means for applying the contents of the table delta to the materialized view 
(abstract and col. 9 line 25-55). 

With respect to claim 24, Witkowski teaches the system set forth in claim 23, 
wherein each of the plurality of entries comprises an epoch identifier (col. 9 line 18-23 
SCN). 

With respect to claim 25, Witkowski teaches the system set forth in claim 24, 
wherein the epoch identifier corresponds to changes that have been made to the table 
since a previous refresh operation on the materialized view (col. 9 line 18-23). 

With respect to claim 26, Witkowski teaches the system set forth in claim 23, 
wherein the means for applying the table delta to the materialized view is adapted to 
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distinguish between a first subset of tlie plurality of entries that have already been 
applied to the materialized view in previous transactions and a second subset of the 
plurality of entries that have not been applied to the materialized view in the event of a 
failure of applying the table delta to the materialized view (col. 9 line 55-col. 10 line 7 
and col. 9 line 34-39). 

With respect to claim 27, Witkowski teaches a computer readable medium, 
comprising: 

a refresh log stored on the machine readable medium, the refresh log containing 
a plurality of entries each of the plurality of entries (col. 9 line 40-50, col. 16 line 17-24 
and figure 4c) comprising an epoch identifier (col. 9 SCN) adapted to synchronize the 
refresh log between refreshing operations, wherein one of the plurality of entries 
comprises refreshable data associated with a materialized view (col. 9 line 25-33 and 
col. 9 line 24-67); and 

code adapted to refresh the materialized view at least in part from a table by 
computing a table delta based on the refresh log and applying the table delta to the 
materialized view. 

With respect to claim 28, Witkowski teaches the computer program set forth in 
claim 27, wherein each of the plurality of entries comprises an epoch identifier (col. 9 
line 18-23 SCN). 



Application/Control Number: Page 13 

10/690,762 
Art Unit: 2167 

With respect to claim 29, Witkowski teaches the computer program set forth in 
claim 28, wherein the epoch identifier corresponds to changes that have been made to 
the table since a previous refresh operation on the materialized view (col. 9 line 18-23). 

With respect to claim 30, Witkowski teaches the computer program set forth in 
claim 27, wherein the refresh manager is adapted to distinguish between a first subset 
of the plurality of entries that have already been applied to the materialized view in 
previous transactions and a second subset of the plurality of entries that have not been 
applied to the materialized view in the event of a failure of a refresh operation (col. 9 line 
55-col. 10 line 7 and col. 9 line 34-39). 

(10) Response to Argument 

A. Ground of Rejection No, 1: 

Appellant's arguments, see page 7 of the Brief, with respect to claims 1, 5, 
9, 16, and 27 have been fully considered and are persuasive. The 35 U.S.C, 112 
second paragraph rejection of claims 1, 5, 9, 16, and 27 have been withdrawn. 

B. Ground of Rejection No. 2: 

Appellant's arguments with respect to the rejection of claims 1-4 under 35 
U.S.C 101 (pages 8-10 of the Brief) have been fully considered but they are not 
persuasive. 
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Claims 1-4 (see rejection above) have been rejected under 35 U.S.C. 101 
because no implementation of computer hardware is found in these claims. As claims 
1-4 are system claims, they lack implementation of hardware to actually define a 
system. Therefore, as can be reasonably interpreted, claims 1-4 can be construed as 
software per se (i.e. a "software" system) because they lack hardware essential to 
perform the functionality of the claim. By lacking the necessary hardware to define a 
system, claims 1-4 are merely a program listing and thus, in other words, functional 
descriptive material. With respect to functional descriptive material, MPEP 2106.01 [R- 
5] section I holds: 

[Similarly J computer programs claimed as computer listings per se, /.e., the 
descriptions or expressions of the programs, are not physical "things. " They are neither 
computer components nor statutory processes, as they are not "acts'' being performed. 
Such claimed computer programs do not define any structural and functional 
interrelationships between the computer program and other claimed elements of a 
computer which permit the computer program's functionality to be realized. 

For the reasons that claims 1-4 lack hardware and can be interpreted as software 
perse, the 35 U.S.C. 101 rejection of these claims are sustained. 

Furthermore, the Examiner notes that found in Appellant's arguments are 
statements concluding that because claims 1-4 produce a useful, concrete, and tangible 
result, recite statutory subject matter (i.e. see Brief, page 9, lines 1-3 of the first full 
paragraph). The Examiner submits that although the Appellant addresses the practical 
application requirement, the core issue (i.e. the claims being software perse for lacking 
hardware) is not contended. 
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C. Ground of Rejection No. 3: 

Appellant's arguments with respect to the rejection of claims 1-30 under 35 
U.S.C 102 (pages 10-12 of the Brief) have been fully considered but they are not 
persuasive. 

The Appellant argues (page 11 second paragraph of the Brief) that Witkowski 
doe not disclose an epoch identifier adapted to synchronize the refresh log between 
refreshing operations. The Examiner disagrees given the following: 

Witkowski discloses in column 9, line 25, a method of an incremental refresh 
operation. In this method, an incremental refresh is performed by applying Dlt_Ti (delta 
table for table Ti) to MV (i.e. a Materialized View) (col. 9 line 28-32). The Examiner 
submits that the delta table (DIt Ti) is synonymous with and thus describes the claimed 
refresh log. This can simply be concluded because the claimed refresh log "contains a 
plurality of entries, each of the plurality of entries corresponding to a change in the 
table." Likewise, Witkowski's delta table stores the rowid rows of the table which have 
changed (Witkowski, col. 9 line 12-14). Further, Witkowski teaches a "delta table" 
SNLog that stores for each changed row of table TI, (1) the rowid of the changed row, 
and (2) the sen that indicates the logical time at which the row was changed (Witkowski, 
col. 9 line 45-48). Because Witkowski teaches a refresh log (i.e. delta table SNLog_Ti) 
that contains a plurality of entries (rowids and sen's) corresponding to a change in the 
table (i.e. the rowids and sen's correspond to changes of rows in a table) that the delta 
table SNLog_Ti describes Appellant's claimed refresh log. 
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With Witkowski describing the refresh log, they also described the claimed epoch 
identifier (as an SCN) adapted to synchronize the refresh log between refreshing 
operations. 

That is, Witkowski teaches the use of an SCN (System Change Number) 
assigned to transactions in commit time order (col. 9 line 17-18). The SCN indicates the 
logical time at which the row was changed (col. 9 line 47-48; i.e. the SCN corresponds 
to a change in the table). The SCN further describes Appellant's "epoch identifier" 
because of the steps in claim 1 utilizing the epoch identifier. That is, in step (a), claim 1 
states "successively reading a first subset of the plurality of entries indicated by a 
specific epoch identifier from the refresh log". In column 9, lines 55-60, Witkowski 
illustrates a query that reads a first subset of the plurality of entries indicated by a 
specific epoch identifier from the refresh log. In other words, Witkowski teaches 
retrieving a specified range of SCN (col. 9 lines59-60) as a first subset of the plurality of 
entries from the SNLog (i.e. Appellants' refresh log). 

Step (b) of claim 1 states "identifying a second subset of the plurality of entries 
from within the first subset of the plurality of entries, the second subset of the plurality of 
entries falling within a primary key range". Furthermore to note Witkowski teaching this 
limitation, the query (top of column 10) describes creating a VTi (a view of the delta 
table containing the SCNs). That, is a subset of the entries of the Dlt_Ti is chosen to be 
included in the VTi table. The subset chosen is done so in primary key order (i.e. 
Ti.rowid = Dlt__Ti.rid wherein 'rowid' and 'rid' are primary keys). 



Application/Control Number: Page 17 

10/690,762 

Art Unit: 2167 

The Examiner submits that from Witkowski teaching the above steps that 
Witkowski would obtain the benefits of avoiding inclusion of records to transactions that 
occurred outside a refresh time range or omit records corresponding to transactions that 
actually within a particular refresh time range (i.e. column 9, line 55-60 shows a query 
retrieving only the SCN s within a refresh time range). 

Moreover, Witkowski teaches the epoch identifier is adapted to synchronize the 
refresh log between refreshing operations. 

The Examiner submits that the delta table SNLog_Ti stores in part the SCN 
(system change number that indicates the logical time at which a change was made 
(col. 9 line 21-23)). Therefore, the SCN produces and ordering scheme (i.e. logical 
timing) within the delta table SNLog_Ti. Furthermore, the Examiner submits that 
snapshot logs may be used to record changes that have been made to base tables after 
the most recent MV (materialized view) refresh (Witkowski, col. 16 line 21-25). The 
delta table SNLog is also seen as a snapshot log because both contain entries 
corresponding to changes in a table. In either case of the SNLog or snapshot log, the 
inclusion of an SCN into a SNLog at least inherently teaches "synchronizing the refresh 
log between refreshing operations." In other words, the Examiner submits that the 
SCNs that are recorded between refresh operations keep the SNLog (claimed refresh 
log) current and therefore synchronized mth the changes made to the table. Witkowski 
describes the use of SCNs between refresh operations (col. 9 lines 50-60) and teaches 
recording the changes that have been made after the most recent MV refresh (col. 16 
line 21-23). The Examiner also submits because the SCN indicates a logical time in 
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change, that the SCN keeps the refresh log synchronized with the changes made (i.e. 
the changes in SNLog are kept consistent with the logical time at which they were made 
and thus are synchronized). 

Furthermore, in response to Appellant's arguments in section 3 grounds of 
rejection (page 12, first full paragraph), the Appellant states that the SCN of Witkowski 
is generally a timestamp. The Examiner disagrees as the SCN of Witkowski is defined 
as a logical time at which a change was made. Therefore, Appellant's assertion is 
incorrect because a timestamp is well known to include the actual time when a change 
was made. At no point in Witkowski's disclosure is an SCN defined as a timestamp. As 
broadly defined in the claims, Witkowski's SCN sufficiently describes the claimed epoch 
identifier (i.e. both the SCN and the epoch identifier serve the same purpose: to 
synchronize the refresh log between operations). The Examiner also wishes to note 
that the present claims do not disclose any changing of the epoch identifier as specified 
by Appellant (page 12, first paragraph, lines 3-5). 

In response to Appellants second paragraph on page 12 of the Brief, it is noted 
that the term "steps" is used in the present claims to describe iterations of a refresh 
operation. In response to this note, the Examiner submits that the "steps" in the claims 
can easily be construed as different invocations of the refresh operation rather than 
different transactions that are part of the same refresh operation (for example, 
Witkowski teaches the claimed steps in an incremental (i.e. suggesting steps; coL 9 line 
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25) operation). The Examiner submits that the Appellant is simply relying on their 
specification to describe the "steps" as iteration because no iteration step is described 
or can clearly be interpreted from the claims. In other words, there is no returning step 
to specify any repetitions or [multiple] iterations of the steps. 

Further, the Examiner maintains that the claimed refresh manager can be found 
in figure 3. Specifically. Witkowski describes figure 3 as a computer system on which 
an embodiment of the invention may be implemented. As the system steps of claim 1 
are taught by Witkowski, this is an embodiment that may be performed by thief figure 3. 
For example, as can be reasonably interpreted, the claimed refresh manger is simply a 
processor of information that performs multiple steps. Likewise, the Examiner submits 
that it can reasonably interpreted that the processor (304) of Witkowski's figure 3 is a 
component of a computer system that can implement the embodiments of their 
invention (e.g. the incremental update). 

The Appellant also states that the cited figure does not even appear to illustrate a 
database system in general. In contrast to this assertion, the Examiner submits that 
figure 3 comprises a server (330) which, in the least illustrates a database system 
(Witkowski's abstract also suggests the server being a database server to teach a 
database system). Also to mention, Witkowski is replete with illustrating a database 
system in other figures (i.e. at least figures 4A-C and 6A-B). 
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(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 

Robert TimbllnAU- 2167 
Conferees: 



Pierre Vital 

JOHN COTTINGHAM 
SUPERVISORY PATENT EXAMINER 
TP0HN0L06Y CENTER 2100 




